1. Field of the Invention
The present invention relates generally to communication between electronic devices. More specifically, the present invention relates to a method and an apparatus for performing vendor-specific communication between electronic devices.
2. Description of the Related Art
Modern computing systems generally include a number of target devices in communication with one or more initiator devices. For example, the initiator device may be a host computer and the target device may be a hard drive connected as a peripheral device. Communication (i.e., data transfer) protocols, such as IDE and SCSI, are used to enable communication between initiator devices and target devices. Standard communication protocols have been developed to ensure communication compatibility between initiator devices and target devices. The standard communication protocols provide rigid frameworks and processes for conducting data transfers between devices. For example, Serial Attached SCSI (SAS) represents a set of standard protocols used for communicating between SCSI devices. SAS includes standard communication protocols such as a Serial ATA Tunneled Protocol (STP), a Serial Management Protocol (SMP), and a Serial SCSI Protocol (SSP).
FIG. 1 is an illustration showing a number of initiator devices (I1–I3) and a number of target devices (TD1–TD4) networked to communicate with each other using standard communication protocols, in accordance with the prior art. Communication between the initiator devices (I1–I3) and the target devices (TD1–TD4) is facilitated by a network. The network can be as simple as a switch or as complex as a series of independent computing systems. Generally speaking, for two devices to communicate (i.e., initiator device-to-target device, target device-to-initiator device, or initiator device-to-initiator device), both devices must be configured to implement a common standard communication protocol. For example, since the initiator device I1 and the target devices TD2 and TD3 each implement a Protocol A, these devices can communicate according to the framework and process defined by Protocol A. In a similar manner, initiator device I2 and target device TD4 can communicate according to the framework and process defined by Protocol B. Also, initiator device I3 and target device TD1 can communicate according to the framework and process defined by Protocol C. However, initiator devices (I1–I3) cannot communicate with target devices (TD1–TD4) that are not configured to implement a common standard communication protocol, vice versa. The use of standard communication protocols, as discussed above, enables compatibility between devices of different vendors.
FIG. 2 is an illustration showing a standard frame structure implemented within a standard communication protocol, in accordance with the prior art. The standard frame structure includes a Start of Frame primitive (SOF). A series of dwords follow the SOF. Each dword represents a set of contiguous bytes or contiguous characters considered as a unit. The standard protocol dictates a type of data that can be included within each dword. A set of cyclic redundancy check (CRC) data follows the series of dwords. The CRC data represents a checksum used to confirm the integrity of the data received in the frame. The frame concludes with an End of Frame primitive (EOF).
Occasionally, it may be desirable to communicate vendor-specific data between devices of a common vendor. For example, the vendor-specific data may be used to implement a unique feature of the target device that is made available only by the target device vendor. Thus, the vendor-specific data in conjunction with the unique feature of the target device may provide the vendor with a competitive advantage. However, the standard frame structures associated with the standard communication protocols are quite limited with respect to an amount of vendor-specific data that can be included. Generally, such vendor-specific data can only be included in a limited number of reserved locations within the standard frame. The reserved locations are typically designated as reserved bytes or a limited number of pre-designated vendor-specific fields contained within the standard frame.
However, using the reserved locations to carry the vendor-specific data introduces complications. For example, devices from other vendors may be expecting particular types of data to be contained within the reserved locations. Thus, use of the reserved locations by multiple vendors to carry different types of data introduces incompatibility issues. Introducing incompatibility issues between devices runs contrary to the primary intent of standardizing communication protocols. Another complication arises in the inability to protect vendor-specific data contained within the reserved locations from interception by competing vendor devices. Interception of vendor-specific data by a competing vendor device may result in a loss of the competitive advantage expected to be gained by using the vendor-specific data.
In view of the foregoing, there is a need for a method and an apparatus that will allow for more efficient and protected vendor-specific communication between devices of a common vendor without rendering them incompatible with devices of other vendors.